A typical automated transfer line, as shown in FIG. 1, consists of a number of work stations where the work piece undergoes various operations, for example metal cutting and forming, in a specific, predetermined order. The flow of the work piece, such as an automotive engine block, from the point of entry into the line, its guidance and navigation through the work stations, and its final exit from the line after successful completion of all automated operations, must be controlled with high order of accuracy to result in the proper synchronization and coordination of the automated transfer line.
It is critical that the operation of the automated transfer line be error free and reliable as the smallest inaccuracy in any part of the control system, such as the communication link between various controls at each work station, can have disastrous results. It is also extremely important that the application program for the automated transfer line be relatively straightforward and reliable for both setup and integration, as well as continuous operation and troubleshooting by the factory floor personnel.
Today, automated transfer line applications generally require logic control (e.g., control of IF . . . THEN conditional actions) and motion control (e.g., control of a servo) and at times process control (e.g., control of the electrical current flow to a welder). It should be noted that motion control can be regarded as a specialized type of process control. Application engineers choose several industrial controllers, each specializing in one of the control technologies (i.e., logic, motion and process control), and each with its own specialized hardware and software implementations. The application engineers then program each of these individual devices, typically using different programming languages and development environments, to control a specific subset of the total industrial automation application. Additional hardware and software interconnections and communications must be added to get the individual devices to work together in a coordinated and synchronized manner. The difficulty and cost of programming, integrating, operating and supporting such a complex system is substantial. Key disadvantages of existing automated transfer line control arrangements include the following:
1. Hardware duplication; each controller usually has its own chassis, computer, I/O and power supply.
2. Multiple operator interfaces and program development support systems; this makes the system more difficult to program, debug and operate resulting in increased system support cost.
3. Error prone inter-connecting logic; the control device interconnections require extra integration time and often represent a major source of the system problems thereby reducing the overall reliability of the total system.
4. Sub-optimized usage of controller performance; generally, one or more of the controllers has much more performance than is required for its assigned portion of the application, and since there is no ability to share workload among different controllers, this excess performance is wasted while the total system cost is increased.
In the typical automated transfer line application shown in FIG. 1, control units 2, 4, 6, 8 and 10 require logic, motion, and/or process control. Accordingly, each of these control units requires multiple industrial controllers. In general, one controller for each control technology will be required at each control unit. The typical implementation process for one of these control units is shown in FIG. 2. The system Integrator or the original equipment manufacturer (OEM) carries the overall responsibility for implementing process plan 20 for an individual control unit. Process plan 20 is developed by a process engineer and the implementation of that plan requires the following tasks to be completed:
A. Separating process plan 20 into individual logic control program steps 22, motion control program steps 24 and process control program steps 26.
B. Selecting, purchasing and integrating individual logic controller(s) 28, motion controller(s) 30 and process controller(s) 32, each having its own hardware, operating system and program development environment.
C. Generating separate programs for each individual controller. In this respect, logic control program steps 22 are typically programmed in graphical ladder language (e.g., Relay Ladder Logic Network); the motion control program steps 24 are typically programmed in RS-274D or a proprietary motion language; and the process control program steps 26 are typically specified in Function Block Networks.
D. Adding inter-controller synchronization interconnections and program logic.
E. Debugging this complex architecture. It is noted that the integrated view of the entire system control, specified via these separate programs, is extremely difficult to observe as the interdependence, coordination and synchronization between the various control components is buried deep within the inter-control communication links and the program for each of the controls. Also, the man-machine interfaces 34a, 34b, and 34c are of a general purpose nature which makes the operation of the entire system very difficult for the factory floor personnel.
F. Documenting, maintaining and supporting the integrated system.
While logic, motion and process control have both sequential and continuous functions, a programmer is concerned primarily with sequential functions with respect to motion control, continuous functions with respect to logic control, and both sequential and continuous functions with respect to process control. Sequential functions are actions which are sequential in nature, while continuous functions are actions which are continuous in nature. Both types of functions will be described in greater detail below.
It has been standard practice to program "sequential" motion control functions using RS-274D or a proprietary motion control language on a computerized numerical control (CNC) or some other type of motion controller, to program "continuous" logic control functions using ladder logic and function blocks on a programmable logic controller (PLC), to program "sequential" process control functions using standard Sequential Function Charts, flow charts, or batch recipes, and to program "continuous" process control functions using Function Block Networks.
Each of these controllers and programs serve a specific need in a portion of the application program and present their own specialized programming environment and unique window into the application domain. Unfortunately, none of these programming techniques can adequately address the entire application requirements alone. When used together, these diverse programming techniques implemented on separate controllers are inefficient, do not integrate or interconnect well, are difficult to operate and troubleshoot, and can be prohibitively expensive. A new, simpler, more integrated solution is needed that does not deviate too far from the methods already used to program and troubleshoot on the factory floor to minimize training time.
Many industrial automation applications require the integration of sequential and continuous programs into a single application program, which controls the sequential and continuous machine processes of an industrial automation application.
Sequential programs are used to control the major sequencing of an application program. Accordingly, sequential program steps are executed only once, one step after the other, like a procedure, waiting for the previous step to complete before the next step is executed. Continuous programs are used to monitor and control environmental conditions either during the entire application program or during specific portions of the application program. Accordingly, continuous programs are scanned repeatedly and executed whenever the qualifying conditions are appropriate.
As noted above, sequential functions are actions which are sequential in nature, and accordingly are most easily and intuitively programmed using sequential programs. Likewise, continuous functions are actions which are continuous in nature, and accordingly are most easily and intuitively programmed using continuous programs.
Examples of sequential functions include:
1. machine operation or sequencing, for example: (a) turn the machine on and wait for all functions to report ready, (b) position the workpiece to be processed, (c) begin processing and wait for the process to complete, (d) shutdown the process, and (e) remove the processed workpiece. This procedure is illustrated by the flow chart shown in FIG. 3. PA1 2. motion control, for example: (a) move from the start position to the first position, (b) move to the second position, (c) go around the corner to the third position, and (d) return to the start position. This procedure is illustrated by FIG. 4. PA1 3. process control, for example: (a) initialize the process output, (b) ramp the process output to level one, (c) wait for some event or signal and then change the process output to level two, and (d) wait for another event and then return the process output to an idle state. This procedure is illustrated by FIG. 5. PA1 1. logic control for scanning operator control input and safety interlocks, programmable interface devices (PID) and other closed feedback loop control, and PA1 2. analog signal processing. PA1 1. each sequential program statement must be associated with a separate SFC step box 40; PA1 2. a "pulsed (P)" type action qualifier 48 must precede each sequential program statement that the action invoked only once; PA1 3. each SFC step must set a boolean output variable when it is "done"; PA1 4. the "done" output variable must be added to SFC transition logic 42 to sequence to the next SFC step; PA1 5. any continuous program statements that are common to several sequential program statements must be repeated for each SFC step having the sequential program statement; PA1 6. and any exception handling actions that are common to several sequential program statements must be repeated for each. PA1 1. because of the techniques used above, the SFC diagram tends to get very large and complicated even for simple application programs; PA1 2. the sequential program statements that should be the major focus of the application program become "buried" in a sea of action statement boxes, the main application program functions become obscured, and the overall application program control flow through the sequential program statements is not easily visualized; PA1 3. since a series of sequential program statements must be separated into individual step boxes, it is not possible to insert a group of sequential program statements, such as RS-274D motion commands, that may have been generated by some external (e.g. CAD) program generating package, as a unit into the application program; PA1 4. there are no action qualifiers that will activate action statements after certain motion and process control events, such as "acceleration complete" or "ramp done."
Examples of continuous functions include:
Although it is possible to emulate a sequential function using a continuous program, it is frequently difficult to do so and is more difficult to understand and interpret because the natural "step after step" representation is lost. It is also less efficient because all steps, not just the current one, are being repeatedly scanned or checked for possible execution. It is usually not possible to emulate continuous functions using sequential programs, because only one or a limited number of parallel functions are executed and then further processing is suspended until the conditions required to transition to the next step are met.
A method is needed to program in a natural and integrated fashion a system performing both sequential and continuous functions. It is noted that the IEC-1131's Sequential Function Charts (SFC), as shown in FIG. 6 are a good method of programming and visualizing a sequence of continuous programs, and that Relay Ladder Logic Networks (RLL) supplemented with Function Block Diagrams, as shown in FIG. 21, is a good approach for programming continuous functions. The IEC-1131 international programming language standard for programmable controllers provides specifications for Sequential Function Charts, Relay Ladder Logic Networks, Function Block Diagrams, Structured Text (ST) and Instruction List (IL).
The standard Sequential Function Chart (SFC) shown in FIG. 6, as specified in the IEC-1131, is intended to provide a graphical means for presentation of an application program for controlling both sequential and continuous functions. Step boxes 40 are used to sequence between program steps. As each step box is activated in turn, the action associated with the step box is scanned and executed.
The sequencing between step boxes 40 works well when the actions associated with each step are continuous functions. In applications, such as motion and process control, where the functions to be performed require a significant finite amount of time to complete and must be performed in a sequential manner, the standard SFC becomes difficult to use. Examples of these sequential functions include moving a motor through a series of positions (See FIG. 4) and issuing a series of process control commands based on time or other event inputs (see FIG. 5).
To use a standard SFC diagram, as shown in FIG. 6, in these applications:
Additional disadvantages to standard SFC programming include:
FIG. 6 shows a typical standard Sequential Function Chart, which consists of step boxes 40, transition logic 42, and action statement box 44. Action statement box 44 is comprised of action statement identifiers 46 and action qualifiers 48. Transition logic 42 is evaluated to form a single boolean result that controls the transitions between steps. Action statements associated with an action statement identifier are executed continuously and in parallel at a regular time interval as long as the step to which the action statement identifier is associated is active. Accordingly, when transition logic 42 for a step becomes true, the action statements associated with the step cease execution and the step is deactivated. This process repeats for each step in the SFC.
All of the productive functions performed by the standard Sequential Function Chart are performed by the action statements associated with action statement identifiers 46. The step labels (e.g., "State 1") associated with each step box 40 serve no useful purpose except to uniquely identify each step. If sequential programs are needed (e.g. for programming sequential functions, such as motion and process control), they are encapsulated inside Function Blocks, contained within actions, along with any other continuous program steps that must be performed in that step.
Action qualifiers 48 are used to specify when associated action statements are to be executed. For example, action qualifier "N" indicates that the action statement associated with action statement identifier "Action 1" is to be executed repeatedly, action qualifier "P" indicates that the action statement associated with action statement identifier "Action 2" is to be executed only once, and action qualifier "D" indicates that the action statement associated with action statement identifier "Action 3" is to be delayed.
Implementing motion and process control commands (i.e., sequential programs) using the foregoing constructs makes standard Sequential Function Charts inefficient and difficult to read. The sequential program statements that can be the dominant action of the application program and source of the processing delay in a given step, are "buried" in a sea of action statements. At the same time the step labels of step boxes 40 do nothing to specify what action is being performed in a given application program step. Also, it has been observed that standard Sequential Function Charts are often too large and too detailed to show enough of the application program on one operator screen so that a good grasp of the operational context can be readily visualized. If a standard Sequential Function Chart is used to display the current status of the application program, it often is scrolled or updated too rapidly on the operator's screen to be of much use.
While attempts have been made in the prior art to provide a system for integrating sequential and continuous programs, none of these approaches have solved the basic difficulties encountered. In this respect, the prior art systems have failed to provide integration of the following capabilities:
1. The capability to program, edit, execute, monitor and debug both sequential programs and continuous programs simultaneously in a single integrated environment.
2. The capability to program in programming languages familiar to the industry segment (e.g. logic, motion, and process control industry) of the application.
3. The capability to put the sequential program in a dominant position in the programming paradigm to control the overall sequence of the application program.
4. The capability to add constructs to the application program to allow the sequential and continuous programs to be synchronized (including specific synchronization constructs needed for motion and process control), wherein the constructs are intuitive and outwardly visible in the integrated environment.
5. The capability to provide a graphical programming environment which presents integrated programming paradigms and a simple and intuitive format which is easy for a new user to learn.
Prior art approaches to integrating sequential and continuous programs includes: computerized numerical control (CNC), flow chart programming, and standard Sequential Function Chart programming.
Computerized numerical controls provide technology which allows the user to write sequential programs using the RS-274D programming language (which is the industry standard for specification of motion control programs) and to write continuous programs using Relay Ladder Logic Networks. Both programs can be programmed and executed on a single hardware platform. However, computerized numerical controls do not allow the sequential and continuous programs to be programmed, edited, executed, monitored and debugged in a single programming environment. In addition, the constructs used by computerized numerical controls to synchronize sequential and continuous programs are embedded in the continuous program and are not easy to visualize. Furthermore, additional program logic must be added by the user to both the sequential and continuous programs in order to properly synchronize them.
Flow chart programming provides technology which allows the user to write sequential programs using a graphical flow chart language. However, flow chart programming is deficient in integrating sequential and continuous programs. In this respect, any continuous program must be simulated by use of many flow charts. This does not allow continuous programming paradigms which are standard in the industry, such as Relay Ladder Logic Networks and Function Block Networks. Furthermore, no constructs are provided to synchronize sequential programs with continuous programs.
Standard Sequential Function Chart programming allows the user to write continuous programs using industry standard Relay Ladder Logic networks and Function Block Networks. These continuous programs are sequenced using Sequential Function Chart step boxes and transition logic. However, sequential programs are subordinate to the continuous programs. In this respect, a sequential program (e.g., a RS-274D program) may be called from a continuous program (e.g., Relay Ladder Logic network), but not vice versa. Importantly, since a sequential program specified in this way is subordinate to the continuous program, the sequential program cannot be used to provide overall sequencing of the application program. Accordingly, the sequential program cannot assume a dominant position in the programming paradigm. Therefore, although standard Sequential Function Chart programming allows continuous programs to be sequenced, this function does not meet the needs of sequential functions performed in most industrial automation applications. Any programming language used in the industry to perform sequential functions (e.g., Structured Text, Fortran, BASIC and RS-274D), must execute subordinate to a continuous program. Consequently, any sequential program used in this way cannot be used to provide sequencing for the application program. For example, a computerized numerical control application which uses RS-274D motion commands to execute a motion profile cannot be implemented using a standard Sequential Function Chart. In addition, no constructs are provided by a standard SFC to synchronize the sequential programs with the continuous programs.
In industrial automation applications, great care must be taken that every foreseeable circumstance, especially those caused by faults or failures in the system be accounted for and handled appropriately by the application program. The machinery might fail, motors may be late getting into position or stop altogether, functions being performed may take longer than expected or may not be able to be accomplished at all, the items being processed may contain some disastrous defect. The programming languages used for these applications must be able to accommodate the addition of routines to handle these exceptions to normal operations.
In the IEC-1131 standard there is no special mechanism in place for exception handling. Actions must be added to the continuous programs to detect the exceptions, but once the exceptions are detected there is no special mechanism in the IEC-1131 standard for the continuous program to force a transition in the
Sequential Function Chart to a new step. This can be accomplished in the IEC-1131 standard by setting a boolean variable in the continuous program and adding transition logic to the Sequential Function Chart to go to a new step. But since each step in the Sequential Function Chart should include checks for several possible exception conditions that may be handled in many different ways, the addition of these exception branches to the Sequential Function Chart make standard SFC diagrams very complicated and make it difficult to discern the normal operation sequence of the application program.
The present invention also addresses several other disadvantages of prior art programming systems. In this respect, the present invention addresses deficiencies of prior art Relay Ladder Logic program editors and of the standard implementation of the RS-274D programming language. The present invention also addresses the deficiencies of prior art approaches to debugging programs and prior art manual application sequencers.
Prior art implementations of Relay Ladder Logic program editors lack several features which make Relay Ladder Logic Networks easier to edit. Once a program is constructed, prior art editors make it difficult to make certain changes to the program that may be necessitated by: (1) errors or omissions in the original application program or (2) changes or additions to the machine's functionality. In some cases, especially when logic branching is involved, in order to add or move relay logic elements and branches to logic rungs, a portion of the ladder rung must be deleted, along with the ladder elements and information entered on the rung, in order to modify the logic rung appropriately. It is not possible on the prior art to move ladder elements, portions of a ladder rung and logic branches around freely in the Relay Ladder Logic Network.
On prior implementations of Relay Ladder Logic program editors, logical outputs are limited to the right hand end of the logic rung. Some editors only allow one output per rung. Others that allow multiple outputs, require that they be entered on separate output branches. These restrictions: (a) cause the logic programs to be less efficient, (b) force replication or addition of logic rungs in order to achieve multiple outputs, (c) limit the use of Function Blocks within the Relay Ladder Logic Network, (d) do not allow logical outputs on "OR" branches or other locations on the logic rung that can be used for diagnostic purposes or to reduce the size and complexity of the Relay Ladder Logic Network.
FIG. 26a shows a Relay Ladder Logic Network with three output coils, namely output coils X52, Y54, and Z56. FIG. 26b shows the corresponding IEC-1131 Instruction List (IL) program that is generated following the rules in the IEC-1131 standard specification. The IEC-1131 standard specification provides rules for embedding an Instruction List (IL) program within a Structured Text (ST) program. FIG. 26b also shows a listing of computer pseudo-code instructions that demonstrate the actions performed by the controller to evaluate the IL program of FIG. 26a.
Prior implementation of algorithms to evaluate boolean logic programs resemble those commonly used for solving algebraic expressions. These algorithms use a single data stack to recursively store partial results and other information required to evaluate the program. Referring to FIGS. 26a and 26b, whenever a logical branch in the ladder logic occurs (e.g., logical branch point 58), as signaled by a left parenthesis "(" in line 14 of FIG. 26b, the logical result calculated thus far is pushed onto the stack, and a new result variable is created [line 16]. At the same time, a deferred operator function "AND" [line 9] or "OR" [line 15] is also pushed onto the stack. The deferred operator indicates the operation to be performed to combine the new result with the old one once logical branch 58 is completed, as signaled by the right parenthesis ")" [line 21]. The new result is initialized to a logical 1 [line 16]. The new result is used to evaluate the ladder logic rung fragment that lies between the branch points 58 and 60 (i.e. between the parenthesis "( . . . )" in IL). When the right parenthesis is encountered [line 21], the deferred operation is popped off the stack [line 21] along with the old result [line 22]. The deferred operator is used to combine the new result with the old result [line 23]. The old result holds the results of the combined operation [line 23] and the new result is discarded [line 24].
The foregoing standard algorithm works well for evaluating Relay Ladder Logic Networks that only have logical output coils at the end of a ladder logic rung, but it does not work for Relay Ladder Logic Networks that can have logical output coils in any location on the rung. This is demonstrated by output coil Y 54 in FIG. 26a that is equal to "A and NOT B and NOT E and F". It is not equal to "NOT E and F" as would be computed by the foregoing standard algorithm. The shortcoming of the standard algorithm is that the new result used to evaluate the "OR" branches is initialized to 1 [line 16]. For arbitrary logical outputs, the "OR" branches of the ladder logic rung must be "AND'd" with the partial results of the ladder logic rung that was computed up to the point where the logical branching occurred [line 17]. A new algorithm for evaluating boolean logic expressions is needed that allows the placement of logical outputs anywhere within the Relay Ladder Logic Network.
Although RS-274D is a popular motion control programming language on the factory floor, it is limited in that the standard commands can only assume numerical values. This prevents RS-274D programs from using computed values as parameters, controlling the flow of application programs, and synchronizing with other system input-output (I/O) activities. Accordingly, enhancements to the standard RS-274D programming language are needed to improve the utility of the programming language.
Another problem encountered with prior art programming systems is that it has been difficult to debug application programs having intermittently occurring problems. In this respect, the conditions that cause the problem are often difficult to locate and repeat, are complex, and may appear and disappear rapidly. Furthermore, an engineer may not be present to observe the system when the problem occurs, or the problem may be difficult to identify because it can reside with either the hardware or the software. Prior art debugging programs have failed to provide a system which addresses the foregoing problems.
With respect to prior art approaches to debugging, some programmable logic controllers (PLC) provide I/O contact histograms and/or I/O timing diagrams. Some prior art controllers provide trend diagrams, while circuit emulators provide a program execution trace. However, none of the prior art controllers use this information to replay the events using the application program to graphically replay program execution and system-wide status information simultaneously on the same display. Accordingly, a new system for debugging is needed to overcome the limitations of prior art systems.
Many industrial applications today are operated by personnel which have had little exposure to computer technology. This requires that the operator interface for the application be very simple and intuitive to use with a minimal amount of training. Many application programs follow a simple sequence of steps which must be followed in a specific order. Also, in many applications, specific steps must be periodically performed. The operator in such applications are frequently required to manually sequence the application program through these steps in order to observe the results, sometimes taking measurements, sometimes making adjustments, and sometimes executing a special operation.
Prior art systems provide a software interface which ties a simple sequence of operator buttons to the steps of an application program to allow the operator to manually sequence the steps. In the prior art, the application engineer must individually create each button and link the button control and status to the individual steps of the application program. A new method is needed which will create this sequenced set of operator buttons and automatically link the operator buttons to the application steps, providing standard functionality for button control and status.